do we need a controller per container? can we not follow the model we have for devices/* and have one controller for all containers?
i doubt that each container needs to track its [scsi|plan9|vPCI]Controller

similar for the process controller; having one controller for all processes in a container would probably be cleaner

Collapsing all containers/processes into a single controller would make workflow cumbersome and introduce a host of problems. The two patterns (linuxcontainer vs device controllers) are solving different problems:

• Device singletons exist to dedupe + refcount shared host resources — multiple containers can reference the same SCSI disk, so one controller centralizes the reservation/refcount and ensures the VM-level attach happens once.
• Containers don't have any shared state to dedupe. Every field on linuxcontainer.Controller is strictly per-container: the GCS container handle, state machine, terminatedCh, processes map, per-container reservation lists, and a mutex scoped to that container's lifecycle. Two containers never refer to "the same container" the way they do the same disk.
  • If we collapsed it, we'd end up with map[cid]*containerState inside one big controller — i.e. the same struct moved one level down. No real consolidation, but real costs:
    • Locking gets worse — either one big mutex held across long GCS calls, or per-entry sub-locks (which is what we already have).
    • Lifecycle ownership blurs — today pod.Controller = registry, linuxcontainer.Controller = container lifecycle, process.Controller = process lifecycle. Each has its own Wait/teardown workflow. Merging the middle layer conflates registry with lifecycle owner.
  • The "central tracker" already exists — it's pod.Controller. Cross-container ops (kill --all, sandbox-delete precondition checks) already go through podCtrl.ListContainers() in service_task_internal.go without forcing containers to share a controller.

TL;DR: device singletons fit shared, refcounted host resources; containers are independent entities with their own state machines, and pod.Controller already plays the central-registry role.

Also, I hear your concern about the proliferation of the controllers but it's not going to be worse than what we already have with containerd-shim-runhcs-v1. hcsTask corresponds to a single container and hcsExec corresponds to a single exec/process.